<p>Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:</p>
<ul>
  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10654">CVE-2018-10654</a>: Hazelcast Library: Java deserialization
  vulnerability </li>
  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000058">CVE-2018-1000058</a>: Jenkins Pipeline: arbitrary code execution
  vulnerability </li>
</ul>
<p>Object deserialization from an untrusted source can lead to unexpected code execution. <code>ObjectInputStream</code> doesn't provide a way to
apply rules on its <code>InputStream</code> argument. Knowing that all serializable classes in the scope of the classloader will be deserialized,
there is a possibility that malicious code could be executed during the deserialization phase even if, in the end, a <code>ClassCastException</code>
will be raised.</p>
<p>Deserialization takes a stream of bits and turns it into an object. If the stream contains the type of object you expect, all is well. But if
you're deserializing untrusted input, and an attacker has inserted some other type of object, you're in trouble. Why? There are a few different attack
scenarios, but one widely-documented one goes like this: Deserialization first instantiates an <code>Object</code>, then uses the
<code>readObject</code> method to populate it. If the attacker has overridden <code>readObject</code> then he is entirely in control of what code
executes during that process. It is only after <code>readObject</code> has completed that your newly-minted <code>Object</code> can be cast to the
type you expected. A <code>ClassCastException</code> or <code>ClassNotFoundException</code> will be thrown, but at that point it's too late.</p>
<h2>Ask Yourself Whether</h2>
<ul>
  <li> an attacker could have tampered with the source provided to the deserialization function. </li>
  <li> you are using an unsafe deserialization function. See the <strong>Recommended Secure Coding Practices</strong> for examples of safe libraries.
  </li>
</ul>
<p>You are at risk if you answered yes to any of those questions.</p>
<p> </p>
<h2>Recommended Secure Coding Practices</h2>
<p>To prevent insecure deserialization, you should either use look-ahead deserialization (pre-Java 9) or a filter to make sure you're dealing with the
correct type of object <em>before</em> you act on it.</p>
<p>Several third-party libraries offer look-ahead deserialization, including:</p>
<ul>
  <li> ikkisoft's <code>SerialKiller</code> </li>
  <li> Apache Commons Class IO's <code>ValidatingObjectInputStream</code> </li>
  <li> contrast-rO0's <code>SafeObjectInputStream</code> </li>
</ul>
<p>Note that it is possible to set a deserialization filter at the level of the JVM, but relying on that requires that your environment be configured
perfectly. Every time. Additionally, such a filter may have unwanted impacts on other applications in the environment. On the other hand, setting a
filter as close as possible to the deserialization that uses it allows you to specify a very narrow, focused filter.</p>
<p>You should also limit access to the serialized source. For example:</p>
<ul>
  <li> if it is a file, restrict the access to it. </li>
  <li> if it comes from the network, restrict who has access to the process, such as with a Firewall or by authenticating the sender first. </li>
</ul>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Deserialization_of_untrusted_data">OWASP - Deserialization of untrusted data</a> </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization">OWASP Top 10 2017 Category A8</a> - Insecure Deserialization
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/502.html">MITRE, CWE-502</a> - Deserialization of Untrusted Data </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#OBJECT_DESERIALIZATION">OBJECT_DESERIALIZATION </a> </li>
</ul>

